In contemporary computing systems, the development of markup language technology has resulted in a straightforward way for program authors to provide valuable information to users, and to receive requests and the like corresponding to user interaction with the displayed information. In general, the markup is processed to construct an element tree, and then the element tree is processed for rendering corresponding output data onto a display.
U.S. patent application Ser. Nos. 10/693,630 and 10/693,822 are among several patent applications (assigned to the assignee of the present invention) that among other things, describe one such markup language that is generally arranged to simplify program authoring, namely XAML (eXtensible Application Markup Language). In general, a program author uses XAML instructions along with calls to application programming interfaces (APIs) to place objects in a scene graph data structure. For example, to build a user interface, a XAML-based program generally adds child visual objects to other visual objects to build up a hierarchical scene graph, writes instruction lists such as geometry data, image data and other data for output, and may specify transform, clipping and opacity properties on visual objects.
One of the capabilities of XAML described in the aforementioned patent applications is the ability to allow programs to specify animation parameters and/or media-related data, and then efficiently output corresponding display data that includes corresponding animations and/or media. For example, a program author may describe a desired animation effect in terms of parameters, such as how much some displayed object property should change over time; for example, a rectangle's opacity property may be set to gradually fade from opaque to transparent, and then back, over some duration. In typical situations, the system manages the animation so that the program code need only specify the animation parameters initially, rather than requiring the program code itself to regularly redraw a changed image over time to accomplish the effect.
To this end, in one implementation, the operating system provides for use of a timeline object that defines the evolution of an animation over time, and as needed, a clock object is instantiated to represent the timeline for that animation. Instead of regularly calling back (e.g., once per frame) to the application program to redraw the animated image with its updated characteristics, the clock is used by the lower-level graphics components to determine the updated, time-variable property parameter or parameters for the displayed object that is being animated, and the image is then redrawn based on the updated property data. In general, media is similarly handled.
While such straightforward programming thus provides a program author with an improved and simplified way to implement animations and media as part of a user interface, timing information heretofore had to be individually applied to each animation or media element. As a result, the program author heretofore needed to manually synchronize various actions that may occur on different timelines, (e.g., the start and stop times of animations and media, and/or how events that are received are handled. This can lead to inconsistent states, such as one animated property being ahead of another animated property (at least temporarily), even though the program author would like both to be synchronized. This also adds complexity; for example, upon a restart event, the individual animations related to that event each need to be found and restarted.